
b) parsing of transaction to the recipients pre-determined format based on the 
overall database structure map; 

c) determining the recipient of at least one transaction, building the outbound 
transaction and forwarding to the transaction engine queue; 

d) building and managing of at least one future conversational transaction 
and forwarding the future transaction to the reply requirements queue; 

e) compressing, logging and encoding the outbound transaction; 

f) transmission of the transaction to it's final destination. 

82. (New) The queue based method for sending an outbound transmission of a 
business conversation according to claim 81 wherein the final destination of the outbound 
transmission is selected fi-om the group of the web host server and third party server on the first 
network. 



REMARKS 

The changes to the specification are to correct typographical errors in the 

specification. 

The new claims 60-82 have no new matter as the newly incorporated claim 
limitations are either disclosed in the original specification or inherent in the art. The claim 
limitations concerning the plurality of network segments is not new matter as the disclosure 
indicates that the present invention can be utilized on a LAN/WAN and a variety of network 
types (see page 6, line 26, page 13, line 26; page 15 line 21 - page 16 line 8 and Figure 1) and it 
is well known in the art that these networks are often comprised of more than one segment. The 
limitations that the network segments may be wireless, fiber optic, or infi-ared is not new matter 
as these types of network segments are very well known to those skilled in the art at the time of 
the invention and these limitations narrow the more broader limitation of a network. For similar 
reasons, the limitation of a web browser is not new matter as it is disclosed on page 28, lines 16- 
1 7 that the present invention may work with HTTP and it was well known in the art at the time 
of the invention to use web browsers to access data on HTTP servers. The claim limitation that 
the initiator is a hand held computer is not new matter as a hand held computer is a specific type 
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of computer and is well known to those skilled in the art. Finally, the claim limitation that the 
data may be either text, binary, image, sound, or stream is not new matter as these types of data 
were well known in the art at the time of the invention. Claims 75 - 82 do not constitute new 
matter as the queue based method for initiating and managing a business conversation is 
described in the original specification in Figures 34-42 and on page 43 line 8 through the end of 
page 50. 

If there are any fees necessitated by the foregoing communication, please charge 
such fees to our Deposit Account No. 50-0902, referencing our Docket No. (75637/1 1931). 
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MARKED UP VERSION OF AMENDMENTS TO SPECIFICATION: 

On page 43, the third paragraph, beginning on line 19: 

The first process flow shown in FIG. 35 begins at inbound request 3501. The inbound 
request 3501 is the event trigger for step 3502 which in turn initiates step 3401. Step 3401 is 
further shown in FIG. 36. The process flow in step 3401 results in the update of the [transport 
protocol outbound queue 421] transaction engine queue 417 with the inbound request. 

On page 43, the paragraph bridging page 43 to page 44: 

From start block 3600 of FIG. 36, step 3601 receives and unpacks the inbound request 
and logs the request in activity log 422. Next, in step 3602, the initiator and responder are 
determined using the trading partner profile table 413. Step 3603 then decodes and 
decompresses the request using a pre-established and exchanged pair of encryption keys. Next, 
step 3604, using overall database structure 414, determines the output destination of the contents 
of the inbound request. The destination of the contents would be located in any allowable 
directory, on any compatible device connected to network 105, and would include, but not be 
limited to an ASCII text file or a dynamic data exchange (DDE) which is electronically passed to 
any program which allows DDE and has been given the rights to execute such a file. Further, if 
the inbound request is EDI structured, step 3605 sends a standard EDI997 functional reply to the 
[transport protocol outbound queue 421] transaction engine queue 417 to confirm receipt of the 
request. Then, in step 3606, the contents are output to the determined destination, either in file 
fonnat as shown in block 3606, or in DDE format as in block 3607. The sub-process ends at 
finish block 3608. The transaction engine inbound process, as further shown in FIG. 37, is the 
preferred destination of the inbound transaction. 

On page 47 the first paragraph beginning on line 1 : 

FIG. 39 is a flow diagram of the SDS inbound. From start block 3900, step 3901 receives 
and reads the transaction and, using data from overall database structure 414, determines the 
routing path and presentation method for processing the transaction. The presentation method 
preferably includes a choice o f one or more of : the direct application of data to an identified 
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database, the dynamic data exchange (DDE) with another appUcation, the output of data as text 
to a file, and/ or the presentation of the data to the graphical user interface of the back office 
application 509 in the form of simulated keystrokes. Step 3902, using data from overall database 
structure 414, formats the transaction according to the method(s) determined, and step 3903 
sends the transaction to the application server 106 according to the determined method(s). Once 
step 3903 is complete, the process ends at finish block 3904. 



MARKED UP VERSION OF AMENDED CLAIMS 

59. (Amended) A system for exchanging data, comprising 

a) a third party server; 

b) a web host server; 

c) a commerce server having a trading partner profile table; 

d) a first network connecting the customer computer, web host 
server and commerce server; 

e) an applications server connected' to the commerce server by a 
second network, the applications server responsive to remote procedure calls 
from the commerce server; 

f) the initiator which initiates the transaction is selected from the group 
consisting of the application server, third party server, web host server, and web 
commerce server; 

g) the responder which receives the transaction selected from the group 
consisting of the application server, third party server, web host server, and web 
commerce server; 

h) , a point to point secure transfer protocol using high level encryption, the 
protocol comprising: 

1) computer readable instruction code means for accessing the trading 
partner profile table and determining the identity of the initiator and responder, 
what transactions the initiator and responder have mutually agreed to allow, 
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determine a location and a format of data for the transaction, and determine 
allowable values; 

2) computer readable instruction code means for generating a unique 
encryption key pair for each transaction; 

3) computer readable instructions for converting data from the 
initiator to a standardized format 

4) computer readable instructions for encrypting the data using one of 
the unique encryption key pair; 

5) computer readable instruction means for sending the data to the 
responder; 

6) computer readable instruction code means for decrypting the data; 

and, 

7) computer readable instructions for converting data from the 
standardized format to the format utilized by a pre-defined format for the 
responder]. 

60. (New) The system for exchanging data as in claim 59, wherein the first network 
comprises a plurality of segments. 

61. (New) The system for exchanging data as in claim 60, wherein at least one 
segment of the first network is selected from the group consisting of wireless, fiber optic, 
infrared, a hand held computer, and a voice recognition device. 

62. (New) The system for exchanging data as in claim 59, wherein the second 
network comprises a plurality of segments. 

63. (New) The system for exchanging data as in claim 62, wherein at least one 
segment of the second network is selected from the group consisting of wireless, fiber optic, 
infrared, a hand held computer, and a voice recognition device. 
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64. (New )The system for exchanging data as in claim 63, wherein the initiator further 
comprises a web browser. 

65. (New) A method for exchanging data, comprising; 

a) an initiator who initiates the transaction, the transaction including data, 
selected from the group consisting of an application server, a third party server, a 
web host server, and a commerce server; 

b) a responder which receives the transaction selected from the group 
consisting of the application server, the third party server, the web host server, and 
the commerce server; 

c) a point to point secure transfer protocol using high level encryption for 
sending and receiving the transaction, the protocol comprising; 

1) computer readable instruction code means for establishing an 
active listener via an event wait state; 

2) computer readable instruction code means for accessing the trading 
partner profile table and determining the identity of the initiator, what • 
transactions the initiator and responder have mutually agreed to allow, 
determine a location and format of data for the transaction and determine 
allowable values; 

3) computer readable instruction code means for generating a security 
error and terminating the code if the initiator is not authorized; 

4) computer readable instruction code means for writing activity to an 
activity log; 

5) computer readable instruction code means for determining and 
processing an event state, the event state selected from the group 
consisting of idle, session request, session confirm, key request, key 
confirm, data package, next data package, package confirm, end request, 
and end confirm; 
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6) establishing a business conversation between trading partners, the 
business conversation comprised of specific time or event driven 
transaction sets; 

7) computer readable instruction code means for building a header 
and cargo appropriate for the event state; 

8) computer readable instruction code means for generating a unique 
encryption key pair for each transmission; 

9) computer readable instructions for compressing and encrypting the 
data using the unique encryption key pair; 

10) computer readable instruction means for sending the data to the 
responder that prevents the data from being stored on a server hard drive 
while the data is in transit between the initiator and responder; 

1 1 ) computer readable instruction code means for receiving, decrypting 
and decompressing the data. 

66. (New ) The method for exchanging data as in claim 65, wherein the data 
comprises at least one of the group consisting of text., binary objects, image, a sound recording, a 
data stream, EDI, XML, and EDIFACT. 

67. (New ) The method for exchanging data as in claim 65, wherein a unique 
signature key generated on the hosting system is derived from a passphrase generated from user 
input and unique system identifiers facilitating non-repudiation. 

68. (New) The method for exchanging data as in claim 65, wherein sharing of public 
keys is directly between trading partners only and used during a single session only. 

69. (New) The method for exchanging data as in claim 65, wherein the initiator's and 
responder's public keys are uniquely created by the insertion of string values into randomly 
chosen positions, 

70. (New) The method for exchanging data as in claim 65, wherein bi-directional 
verification of sender and recipient identities is accomplished prior to any exchange of data. 

71. (New ) The method for exchanging data as in claim 65, wherein separate 
exchanges of public signature keys, used for trading partner validation, and public exchange 
keys, used for encoding/decoding of data, are facilitated. 
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72. (New) The method for exchanging data as in claim 65, wherein the initiator 
maintains full control of data provided to vaUdated partners. 

73. (New) The method for exchanging data as in claim 65, wherein an entire data 
package is encoded prior to transmission. 

74. (New) The method for exchanging data as in claim 65, wherein data receipt by 
the intended recipient is verified. 

75. (New) A queue based method for initiating and managing a business 
conversation, wherein an inbound transmission originates from the group consisting of a web 
host and a third party server, the business conversation comprising at least one transaction and 
comprising a commerce server, the commerce server comprising a trading partner profile table, a 
transaction engine queue, a reply requirements queue, a transaction engine outbound queue, a 
SDS transaction queue, and a transport protocol outbound queue, the commerce server being 
communicatively coupled by a first network to at least one of a web host server and a third party 
server, and the commerce server being communicatively coupled by a second network to an 
application server, the steps comprising: 

a) receiving an inbound request, determining the initiator and responder, 
decode and decompress the request, determine the output destination and adding to the 
transaction engine queue; 

b) parsing the inbound transmission into at least one transaction, authorizing 
the initiator, preparing a data structure for each transaction and returning the transaction to the 
transaction engine queue; 

c) building and managing the business conversation by utilizing the business 
transaction map and forwarding the transactions to the appropriate queue selected from the reply 
requirements queue, the transport protocol outbound queue and the SDS transaction queue; 

76. (New) The queue based method for initiating a business conversation according 
to claim 75 wherein the inbound transmission is received from the group consisting of the web 
host server and third party server communicatively coupled to the first network. 

77. (New) The queue based method for initiating a business conversation according 
to claim 75 wherein the final destination of the transaction is the application server. 
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78. (New) The queue based method for initiating a business conversation according 
to claim 75 wherein step (c) further comprises building and managing at least one future 
conversational transaction and forwarding the future transaction to the reply requirements queue. 

79. (New) The queue based method for initiating a business conversation according 
to claim 75 wherein step (c) further comprises sending an outbound transaction to the transport 
protocol outbound queue. 

80. (New) The queue based method for initiating a business conversation according 
to claim 75 wherein step (c) further comprises sending the transaction from the SDS transaction 
queue to its final destination, the application server. 

8 1 . (New) A queue based method for initiating and managing a business 
conversation, wherein an outbound transmission originates from an applications server, the 
business conversation comprising at least one transaction and comprising a commerce server, the 
commerce server comprising a trading partner profile table, a transaction engine queue, a reply 
requirements queue, a transaction engine outbound queue, a SDS transaction queue, and a 
transport protocol outbound queue, the commerce server being communicatively coupled by a 
first network to at least one of a web host server and a third party server, and the commerce 
server being communicatively coupled by a second network to an application server, the steps 
comprising: 

a) receiving an outbound transaction, reading, parsing and formatting of the 
transaction and adding to the transaction engine outbound queue; 

b) parsing of transaction to the recipients pre-determined format based on the 
overall database structure map; 

c) determining the recipient of at least one transaction, building the outbound 
transaction and forwarding to the transaction engine queue; 

d) building and managing of at least one future conversational transaction 
and forwarding the future transaction to the reply requirements queue; 

e) compressing, logging and encoding the outbound transaction; 

f) transmission of the transaction to it's final destination. 

82. (New) The queue based method for sending an outbound transmission of a 
business conversation according to claim 81 wherein the final destination of the outbound 
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transmission is selected from the group of the web host server and third party server on the first 
network. 
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